Analyzing and debugging systems using communications among their components has become increasingly difficult. Rising complexity, increasing performance, and variety of protocols within a circuit present difficult obstacles for validation engineers attempting to identify and track errors.
A protocol analyzer is an instrument that is designed to display, validate, and measure communications. Such communications may include data in a variety of protocols. The protocol analyzer typically presents packets and transactions for analysis by a user. The packets and transactions are typically represented in a “box car” format by displaying boxes with a text label for a field of a packet and a text message corresponding to the data within the field. A color may be used to distinguish fields from one another.
Unfortunately, data from differing protocols are displayed in the same “box car” format. Thus, without a detailed inspection of a field of the data, the user cannot determine a difference between the protocols or between packets within a protocol. In addition, the box car diagrams for different protocols may be displayed in separate screens, making it difficult to correlate events among the protocols.
In addition, packets are commonly displayed with earlier fields on the left and later fields on the right. Subsequent packets are displayed below older packets. Although a packet may have a field indicating a time, there is no visual indicator of the time relationship of the packets. In particular, there is no visual indicator of a time relationship between packets from different channels or communications links. Thus, it is difficult for a user to correlate the occurrence of packets over time. Although a user may reorder the packets to view packets associated with a particular transaction, there is no visual indication of the time relationship of that transaction with other packets or transactions.
Furthermore, a user may zoom in or out on the display of the packets. However, since the information contained within the fields of the packets are represented by text, as a user zooms out, the text eventually becomes unintelligible. Thus, it is difficult for a user to both view a large number of packets and still be able to determine the information contained within the packet.
Users are typically most interested in errors. A different color may indicate that a field, packet or other structure include an error. However, since color has been used extensively to identify different fields, a different color for an error does not draw the user's attention to it in a sea of other colors. In addition, users are able to arbitrarily assign colors. As a result, the effectiveness of color to indicate an error is reduced further.
In a box-car display, an arrow can indicate of a direction of a packet. However, the arrow only indicates whether the packet is sent toward or away from a root complex. In addition, the user must decode an identification field in the packet to determine which device is sending the packet. A user must rely on this textual device identification to manipulate the view of the packets.
Accordingly, a need remains for an improved display of protocol-specific information.